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Remarks 

Claims 1-22 and 28-33 are currently pending in the subject application and are 
presently under consideration. Claims 1, 7 and 28 has been amended as shown at page 2- 
7 of the Reply 

Favorable reconsideration of the subject patent application is respectfully 
requested in view of the comments and amendments herein. 



1. Rejection of Claims 1-14, 21, 22 and 28 Under 35 U.S.C. §103(a) 

Claims 1-14, 21, 22 and 28 stand rejected under 35 U.S.C. §103(a) as being 
obvious over Release 8.0 of the Workflow Template software product ("Template") 
publicly available from Template Software, Inc. in 1998 as evidenced by "Using the 
WFT Development Environment", 1998 (hereinafter Using WFT) and "Developing a 
WFT Workflow System," 1998 (hereinafter DevelWFT) in view of "XML based Process 
Management Standard launched by Workflow management Coalition -'Wf-XML'," July 
7, 1999 [online], accessed 01/03/2006, Workflow Management Coalition, 
URL:http://vvwvv. wfmc.org/pr/prl999-07-07.pdf , 4 pages(hereinafter referred to as 
WFXML-99). This rejection should be withdrawn for at least the following reasons. The 
Template(UsingWFT and DevelWFT) and WFXML-99 documents, either alone or in 
combination, do not teach or suggest each and every limitation recited in the subject 
claims. 



To reject claims in an application under §103, an examiner must 
establish a prima facie case of obviousness. A prima facie case of 
obviousness is established by a showing of three basic criteria. 
First, there must be some suggestion or motivation, either in the 
references themselves or in the knowledge generally available to 
one of ordinary skill in the art, to modify the reference or to 
combine reference teachings. Second, there must be a reasonable 
expectation of success. Finally, the prior art reference (or 
references when combined) must teach or suggest all the claim 
limitations. See MPEP §706.02(j). The teaching or suggestion to 
make the claimed combination and the reasonable expectation of 
success must both be found in the prior art and not based on 
applicant's disclosure. See In re Vaeck, 947 F.2d 488, 20 USPQ2d 
1438 (Fed. Cir. 1991). 



8 



09/560,373 



MS147248.01/MSFTP101US 



Applicants' claimed subject matter relates to a system and method for modeling 
business workflow processes and reducing the processes to a useful programming 
language for use in real world applications. To this end, independent claim 1 recites: 
providing a user interface to allow a user to explicitly define a dividing of the reduced 
business process into at least one independent transaction and at least one parent 
transaction, the user explicitly defines the at least one independent transaction is not 
interdependent with the at least one parent transaction, the user explicitly defines the at 
least one parent transaction has two or more child interdependent transactions that are 
each different from each other and interdependent with each other, the user explicitly 
defines each child transaction receiving data from the at least one parent transaction 
that is at least partially different from data received by the other child transactions, the 
user explicitly defines the child transactions are children of the parent transaction, 
wherein at least one of the child interdependent transactions is dependent on at least 
one other of the child interdependent transactions for completion; executing the at least 
one independent transaction independently from the at least one parent transaction to 
increase throughput and decrease latency of the business process, the at least one 
independent transaction commits upon successful execution; executing the child 
interdependent transactions independently from each other, the at least one parent 
interdependent transaction commits after all child interdependent transactions have 
committed; and transferring committed data associated with the at least one independent 
transaction and the at least one parent transaction to a computer component for further 
processing. 

Template(UsingWFT and DevelWFT) and WFXML-99, either alone or in 
combination, fail to teach or suggest these exemplary features of applicants' claimed 
subject matter. Template discloses a Workflow Design Editor (WDE) that enables one to 
design a workflow system at a high level. In particular, the Office Action asserts that the 
Template- UsingWFT and DevelWFT discloses a copy flow and a compound flow that 
together disclose concurrently executing interdependent child transactions. However, the 
cited features disclose parallel tasks, but fails to provide any discussion of 
interdependence between the tasks. The subject claim recites that the interdependent 
child transactions are dependent on each other for completion. The cited example from 
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Template discloses two tasks, Approve Fund and Check Inventory, which are not 
dependent on each other for completion. In fact, they are tasks that are completed by two 
separate individuals that are completely independent of each other and do not require any 
information from each other to complete their tasks. Therefore, the tasks are independent 
tasks, not interdependent, that can each complete independently of each other. The 
Examiner asserts that the AND junction implies that the Approve Fund and Check 
Inventory task which precede the AND junction box must collectively commit at the 
AND junction. However, the cited reference does not teach or suggest this aspect of the 
Examiner's assertion. In fact. Template is in fact silent regarding committing 
transactions. The tasks are performed by difference individuals and do not require any 
exchange of information to complete. As such, there is no reason to believe they must 
commit at the AND junction box versus committing on their own independent of eac 
other. Additionally, having various points where transactions commit as recited in the 
subject claims allows for error processing by rolling back a transaction(s) to earlier 
commit points or executing error processing routines at the commit points. Template 
does not discuss these concepts. Furthermore, the Office Action attempts to equate the 
Install Solution task as a parent task to the Approve Fund and Check Inventory tasks. 
However, the Install Solution task is not a parent task to these tasks. It is a subsequent 
task that merely waits for data to be sent from each of the Approve Fund and Check 
Inventory tasks before it begins execution. The subject claim discloses a user explicitly 
defining that a parent transaction has two or more interdependent child transactions and 
the parent task commits upon the last child transaction committing. The cited reference 
is silent regarding a user explicitly defining parent-child relationships between tasks to 
form groupings according to the user's specifications. The Examiner employs logic that 
asserts that since the Install Solution task must wait for the Approve Fund and Check 
Inventory tasks to provide data before starting execution that the Install Solution Task is 
the parent of the Approve Fund and Check Inventory tasks. By this logic, any task would 
be considered a parent of all of the tasks that preceded it in the workflow. For example, 
under this logic, the final task in the workflow would be considered a parent of all of the 
tasks in the workflow, since it must wait to execute until all of the predecessor tasks in 
the workflow complete. There is not basis or precedence in business workflow 
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processing for the Examiner's interpretation using this logic for defining a parent-child 
relationship. Furthermore, by the Examiner's logic, a user would not be able to explicitly 
define parent-child relationships for tasks. It would become a function of the workflow 
process and not under the explicit control of the user. A workflow by its very nature is a 
series of tasks that are execute in a flow task after task. Template fails to discuss the 
concept of a parent task that is made up of child tasks, as well as, a parent task that 
commits separately from its child tasks. By providing flexible transaction grouping and 
commit points, the subject claims allows for more robust data reporting and error 
processing capabilities that are not contemplated in the cited references. Moreover, the 
Examiner contends that Template-UsingWFT provides a copy flow facility that divides a 
reduced business process into at least one independent transaction and at least one parent 
interdependent transaction. While the copy flow facility appears to provide for dividing a 
business process into transactions, it is submitted that the cited document, and 
specifically, the copy flow facility, does not teach or suggest sending disparate work 
items to the destination tasks as taught in the subject claims. Rather the cited document 
specifically states "[a] copy flow is a single flow that splits into two or more flows. ... An 
exact copy of the work item or work item set is sent to each destination task." (See page 
3-20). The facility is incapable of dividing the parent transaction into one or more 
different child interdependent transactions each receiving different data. As evidenced by 
the above cited passage, the cited art sends the same data from the parent transaction to 
each child interdependent transaction. Template is silent regarding divided workflows to 
transactions that are not receiving identical work items. The Office Action attempts to 
introduce the manager' s name and approval date as evidence of receiving disparate data 
in the work items. However, this data is not part of the received work item of the 
Approve Requisition task. It is instead part of the work item that is sent out of the 
Approve Requisition task. The claimed subject matter in contrast is capable of dividing a 
reduced business transaction into a plurality of independent transactions and one or more 
parent transactions wherein the one or more parent transactions can comprise a plurality 
of differing child interdependent transactions that each receives data that is different from 
data received by the each of the other child interdependent transactions. 
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Furthermore, independent claim 7 recites a user interface component; and a 
plurality of model components accessible through the user interface component, the 
plurality of model components allows a user to create a model of a business process and 
reduce the model via the scheduling programming language, the plurality of model 
components comprises a distinguishing model component that distinguishes between 
autonomous business operations and interdependent business operations, the 
autonomous business operations are not dependent on each other for completion and are 
concurrent with respect to each other, the interdependent business operations are 
dependent on each other for completion and are concurrent with respect to each other, 
the interdependent business operations being non-identical and each receiving data 
from a preceding operation that is at least partially different from each other. As 
discussed above. Template fails to disclose the concept of interdependent business 
operations that are dependent on each other for completion and are concurrent. The AND 
junction, contrary to assertions in the Office Action, does not imply any interdependence 
between concurrent operations or that the operations must commit dependent upon each 
other. In addition, the cited reference does not disclose a predecessor operation that 
sends different data to concurrent interdependent subsequent operations. 

Additionally, independent claim 28 recites means for distinguishing between 
synchronization of autonomous operations from interdependent operations, the 
autonomous operations are not dependent on each other for completion and are 
concurrent with respect to each other, the interdependent operations are dependent on 
each other for completion and are concurrent with respect to each other, the 
autonomous operations and the interdependent operations are represented in the 
scheduling programming language, the scheduling programming language written in 
XML, the interdependent operations-each receive data from a preceding operation that 
is at least partially dissimilar with respect to data received by each interdependent 
operation; means for expressing synchronization constraints on completion of 
autonomous operations; and means for allowing association of transaction operations 
and groups of business operations. Template fails to teach or suggest interdependent 
operations that are concurrent and dependent on each other for completion, and also fails 
to teach concurrent interdependent operations that receive differing data from a preceding 
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operation as noted supra. 

Moreover the Examiner offers WFXML-99 to make up for the acknowledged 
deficiency that Template does not teach or suggest reducing a business process to XML 
code of a scheduling programming language. However, WFXML-99 does not cure the 
elucidated deficiency with respect to Template in regards to independent claims 1, 7 and 
28 as discussed above concerning the novel feature, child interdependent transactions 
that are each different from each other and interdependent with each other, each child 
transaction receiving data that is at least partially different from data received by the 
other child transactions, the child transactions are children of the parent transaction, 
the child interdependent transaction are dependent on each other for completion; . . . 
executing the child interdependent transactions concurrently, the at least one parent 
interdependent transaction commits after all child interdependent transaction have 
committed. WFXML-99 provides a draft specification relating to the provision of XML- 
based exchanges between workflow systems. The cited reference is silent regarding the 
novel features of the subject claims as discussed supra. 

In view of at least the foregoing, applicant's representative respectfully submits that 
Template(UsingWFT and DevelWFT) and WFXML-99, alone or in combination, fail to 
teach or suggest all limitations of applicant's invention as recited in independent claims 1, 7 
and 28 (and claims 1-6, 8-14, 21 and 22 that respectfully depend there from), and thus fails to 
make obvious the subject claimed invention. Accordingly, this rejection should be 
withdrawn. 

11. Rejection of Claims 15-20 and 29-33 Under 35 U.S.C. §103(a) 

Claims 15-20 and 29-33 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Template in view of WFXML-99, as applied to claims 1 and 12 above, 
and further in view of Chen et al. (US 5,940,839). This rejection should be withdrawn 
for at least the following reasons. Claims 15-20 and 29-33 depend from independent 
claims 7 and 28 respectively, and Chen et al. does not remedy the aforementioned 
deficiencies with respect to the Template(UsingWFT and DevelWFT) and WFXML-99 
and the respective independent claims. Chen et al. relates to systems and methods for 
recovering from failures in transactions in nested transactional structures. The cited 
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document, however does not teach or suggest child interdependent transactions that are 
each different from each other and dependent on each other for completion, wherein each 
child transaction receives data that is at least partially different from data received by the 
other child transactions, or that the parent transaction commits when a last child 
interdependent transaction commits. Accordingly, this rejection should be withdrawn. 

Conclusion 

The present application is believed to be in condition for allowance in view of the 
above comments and amendments. A prompt action to such end is earnestly solicited. 

In the event any fees are due in connection with this document, the Commissioner 
is authorized to charge those fees to Deposit Account No. 50-1063 [MSFTPIOIUS]. 

Should the Examiner believe a telephone interview would be helpful to expedite 
favorable prosecution, the Examiner is invited to contact applicants' undersigned 
representative at the telephone number below. 

Respectfully submitted, 
Amin, Turocy & Calvin, llp 

/Himanshu S. Amin/ 

Himanshu S. Amin 
Reg. No. 40,894 



Amin, Turocy & Calvin, llp 
24™ Floor, National City Center 
1900 E. 9™ Street 
Cleveland, Ohio 44114 
Telephone (216) 696-8730 
Facsimile (216) 696-8731 
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